maybe just collectExtendedColumnStatisticsOnWrite ?

Save the result of extractColumnMetadata so that you don't have to call it again at the bottom of this method.

Per other comment, don't have to call extractColumnMetadata again.

Why not includeMaxFileModifiedTime in this situation?

Statistic aggregation during table creation does not have information about file_modified_time yet.

Right, right. Then if the modified time isn't present we just use the current time when the collection is done. Makes sense.

Can you please add a code comment explaining this consideration?
What do we need to have this information available?

We should still test the old thing too

agreed

Please do create a compatibility test with spark to verify that after a CTAS DESC EXTENDED works as intended on Databricks

Nevermind. Trino Delta Lake (on the storage layer) & Databricks (on the metastore properties) have outputs in different places.

Do consider documenting this new property in delta-lake.rst - either in this PR or a follow-up PR

I would wait with documentation until other write operations are implemented if that's ok.

nit: There's no need to change this line. I would revert.

nit: this kind of cosmetic changes can be done in a separate commit.

separate commit

This change make sense only with this commit as it allows collection to have 0 elements. It should throw exception before.

Nevermind. Trino Delta Lake (on the storage layer) & Databricks (on the metastore properties) have outputs in different places.

Can you please add a code comment explaining this consideration?
What do we need to have this information available?

Time is added during statistics update.

Do you mean Maximum File modified time ?

this line is now over line length limit, so --

we put all arguments on one line, or each on separate line

that's minimal change, but that's not how you'd write the code if you were writing the code anew.

.flatMap(entry -> {
    ....
    if (....) {
        return Stream.of();
    }
    return Stream.of(Instant.ofEpochMilli(....));
})
.collect(toOptional());

It sounds like a problem and a workaround, but there isn't a problem

// File modified time does not need to be collected as a statistics because it gets derived directly from files being written
                false);

test_analyze_ -> test_ctats_stats_

can you paste this method contents into testCreateTableAsStatistics above?

testCreateTableAsStatistics has good name and a javadoc, just the contents are worse

nit: unrelated fmt change

nit: unrelated fmt change

nit: each arg on separate line

i know it's preexisting but i don't think we need to assert split count in every test method here. It blurs the test's intent
(perhaps, we don't need it in any test, i don't know, but i am not requesting any change to existing tests)

this would be better:

assertUpdate("ANALYZE " + tableName);